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BEARER SERVICE NEGOTIATION 

FIELD OF THE INVENTION 

This invention relates to cellular telecommunications networks and more 
particularly to a quality-of-service (QoS) negotiation between a communication 
unit and a service provider (i.e.. a bearer such as a radio network) at call set-up or 
at handoff. 

BACKGROUND 
In a typical cellular communication network, a user defines his or her 
service requirements to a bearer (i.e., a service provider) in terms of one or more 
requested quality-of-service (QoS) vectors or requested service vector, RSV. 
Each vector consists of a number of QoS parameters which relate to the required 
service. Alternatively, a user's requirements may be input into a computer or a 
computer application which performs the negotiation with the bearer. The QoS 
parameters may include, but are not limited to, required bit rate (peak, mean 
and/or some other rate), required bit error rate (BER) and required transmission 
delay. In addition, the user may also specify a price parameter for a desired 
service. For a given application, a range of values for each of these QoS 
parameters may be acceptable to the user. For example, in a web browsing 
application, a user normally desires a high bit rate for which the user is willing to 
pay a higher price. However, a user may tolerate a lower bit rate if the user is 
interested in minimizing the price. For some applications, the range of values for 
certain QoS parameters that the user is willing to accept may be. relatively small. 
For example, in a voice application, the user may not be willing to tolerate a 
lower bit rate or a longer transmission delay because of the susceptibility of 
speech data to low bit rates and/or long delays. Under less than acceptable 
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conditions, e.g. , low bit rate and long delay, it may be preferable that the call be 
blocked. 

One way the user can express its service requirements to the service 
provider is to define two QoS vectors, wherein the QoS parameter values in the 

5 first QoS vector represent a desired service, and wherein the QoS parameter 
values in the second QoS vector represent an acceptable (or minium level of) 
service. Typically, the desired QoS parameter values indicate a lower price level 
sensitivity on behalf of the user, as suggested above. In contrast, the acceptable 
QoS parameter values are associated with a higher price level sensitivity. In the 

10 case of speech, the desired value and the acceptable value for certain QoS 

parameters (e.g., maximum transmission delay) may be the same, thus indicating a 
user's unwillingness to accept less than desired values for those QoS parameters. 
The at least two QoS vectors containing the desired and acceptable QoS parameter 
values may be expressed as: 



15 QoS desired = (bit rate maximum , delay m i nmiurn price desired ) 

Q oS minimura - ( bit rate minimum- de,av maximum- P rice acceptable) 

Alternatively, a user may define for the service provider a set of QoS 
vectors , QoS i . . . QoS n , wherein the combination of QoS parameter values in 
vector QoS] represent a desired service, wherein the combination of QoS 

20 parameter values in vector QoS n represent a minimum, but acceptable service, and 
wherein the combination of QoS parameter values in vectors Q0S2 to QoS n .j 
represent acceptable service that is less than the desired service but better than the 
minimum acceptable service. In the web browsing application, for example, each 
of the vectors QoS] to QoS n might contain a different bit rate value. For the 

25 speech application, however, each of QoS vectors QoS j to QoS n may contain the 
same bit rate value, once again, exemplifying that with speech data, a user is 
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generally less likely to accept a QoS that is less than the desired QoS. The set of 
QoS vectors QoS\ to QoS n may be expressed as: 

QoS\ = (bit rate j, delay j pricei) 

Q0S2 = (bit rate2, delay2, .... price2^ 
5 Q0S3 = (bit rate3, delay3, price3) 

Q0S4 = (bit rate4, delay4, price4> 

QoS n = (bit rate n , delay n , .... price n ) 

At call set-up, handover and call re-negotiation, a determination has to be 

10 made as to which service will be used to establish a connection. The requirements 
of the user and the capability of the bearer have to be taken into account. The 
capability of the bearer is also expressed in the form of a QoS vector and may be 
referred to as an offered service vector, OSV. The procedure that attempts to 
match user requirements with bearer capabilities is known as a bearer service 

15 negotiation. The bearer service negotiation process results in the generation of a 
negotiated QoS vector or NSV. In general, a NSV contains QoS parameter values 
that reflect the service which the service provider is capable of providing and 
which satisfy requirements of the user specified values in a RSV. In the event that 
no match between the requirements of the user and the capability of the bearer is 

20 established, the NSV is said to be empty. 

It should be noted that a service provider cannot always guarantee the 
quality of service defined by the NSV. In actuality, the QoS parameter values in 
the NSV merely represent the service which the service provider will attempt to 
achieve for the user at call set-up, handover or call re-negotiation. However, 

25 during the time period between the bearer service negotiation and, for example, 
call set-up, conditions may change due to such phenomena as data traffic 
fluctuation and fading, thereby making it impossible for the service provider to 
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achieve the level of service defined by the NSV. If the service provider cannot, in 
fact, achieve at least the user's minimum acceptable service requirements, the 
bearer service has to be renegotiated, or in the case of an on-going call, handed- 
over (i.e., to a different service provider) or dropped. 
5 What is needed is an efficient and effective bearer service negotiation 

technique for determining whether a service provider can fulfill a user's service 
requirements. A method is, therefore, disclosed for enabling the system to choose 
a resulting or negotiated QoS vector based on user requested QoS vector and 
knowledge about the networks. 

10 SUMMARY 

Accordingly, the present invention provides an efficient method for 
matching the service requirements of a user with one or more levels of service 
provided by a bearer. More specifically, the present invention generates a 
negotiated QoS vector, NSV, which contains QoS parameter values and is one of 

15 the offered service vectors (OSVs) provided by the service provider that satisfy 
the user specified values of a RSV. In generating the NSV, the present invention 
determines the differences between the QoS parameter values contained in the one 
or more RSVs and the QoS parameter values contained in the one or more OSVs. 
In addition, each of the QoS parameter values are mapped on a comparable scale 

20 so as to assign a meaningful weight to each parameter. 

In one embodiment of the present invention a method is provided for 
negotiating a telecommunications connection comprising the steps of: introducing 
a first set of quality-of-service (QoS) parameter values representing a user's 
desired level of service; introducing a second set of QoS parameter values 

25 representing at least one offered level of service from a service provider; 

comparing the QoS parameter values in the first set with corresponding QoS 
parameter values in the second set; selecting a level of service offered by the 
service provider that best satisfies the user's desired level of service based on the 
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step of comparing each of the QoS parameter values in the first set with at least 
one corresponding QoS parameter value in the second set; and establishing the 
telecommunications connection for the user as a function of the selected level of 
service offered by the service provider. 

5 In another embodiment of the present invention a method is provided, in 

negotiating a telecommunication connection between a user and a bearer wherein 
the user specifies values for at least one of a plurality of parameters for a type of 
connection desired, for matching the user specified values with an ability of a 
bearer for satisfying the user specified values comprising the steps of: accepting 

10 values for at least one of a plurality of parameters specified by a user; comparing 
the user specified values with values of corresponding parameters available on said 
bearer; and establishing a connection between the user and a bearer that satisfies 
the user specified values. 

In yet another embodiment of the present invention, a method is disclosed, 

15 in negotiating a telecommunication connection between a user and a bearer 
wherein the user specifies values for at least one of a plurality of parameters 
wherein the parameters form a user specified quality of service (QoS) vector, for a 
type of connection desired, for matching the user specified QoS parameter values 
with an ability of the bearer for satisfying the user specified QoS parameter 

20 values, comprising the steps of: accepting values for at least one of a plurality of 
QoS parameters specified by a user; comparing the user specified QoS parameter 
values with values of corresponding parameters available on said bearer; and 
establishing a connection between the user and a bearer that satisfies the user 
specified QoS parameter values. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

These and other objects, features and advantages of the present invention 
will be readily apparent to one skilled in the art from the following written 
description, read in conjunction with the drawings, in which: 
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Figure 1 illustrates a framework for bearer service negotiation according to 
an exemplary embodiment of the present invention; 

Figure 2 illustrates a first exemplary technique for generating a negotiated 
QoS vector, NSV, from a plurality of offered QoS vectors, OSVs; 
5 Figure 3 illustrates another exemplary technique for generating a NSV 

from a plurality of OSVs; 

Figure 4 illustrates yet another exemplary techniques for generating a NSV 
from a plurality of requested QoS vectors, RSVs, and a plurality of OSVs; and 

Figure 5 illustrates the values of an OSV failing to fulfill the RSV 
10 parameters. 



DETAILED DESCRD7TION 

The present invention involves an effective and efficient technique for 
accomplishing a service bearer. negotiation between a user and a service provider 
(i.e., a bearer service). In general, the technique involves comparing one or more 

15 user-defined service requirements with one or more levels of service offered by a 
service provider and, if possible, selecting the level of service that best satisfies 
the user's service requirements. This may be accomplished by a three step 
process in which: (i) one or more requested QoS vectors, RSVs, are introduced by 
the user and one or more offered QoS vectors, OSVs, are introduced by the 

20 service provider respectively; (ii) the QoS parameters contained in the various 
QoS vectors are normalized by applying an appropriate scaling factor; and (iii) a 
negotiated QoS vector, NSV, is chosen from amongst the one or more OSVs, 
where the NSV represents the OSV that best satisfies the user's service 
requirements. 

25 As an alternate way of specifying the price parameter as part of the RSV, 

the user may also specify a price sensitivity level parameter for a desired service. 
This parameter may generically be specified as high or low. For a given 
application, a range of values for each of these QoS parameters may be acceptable 
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to the user. For example, in a web browsing application, a user normally desires 
a high bit rate for which the user's sensitivity level to price is low. However, the 
user may tolerate a lower bit rate if the user's sensitivity level to price is high. 
With this approach to price, the QoS will contain a price sensitivity level 
5 parameter. Referring to the above described instance of desired and minimum or 
acceptable level of service, the sensitivity level may be low for desired service and 
high for minimum or acceptable level of service. 

A general framework for matching a user's service requirements with a 
service provider's capabilities, according to exemplary embodiments of the present 
10 invention, is illustrated in Figure 1. In accordance with Figure 1, and in 

accordance with the first step in the three-step method of the present invention, 
one or more RSVs 110 are introduced to the bearer service negotiation framework 
100. The bearer service negotiation framework 100 then accesses one or more 
OSVs 120. Within the bearer service negotiation framework 100, the one or more 
15 RSVs 1 10 and the one or more OSVs 120 are compared, as explained in greater 

detail below. The bearer service negotiation framework 100 then generates a NSV 
130 if, in comparing the requirements of the user (i.e., the QoS parameter values 
in the RSVs 110) and the capabilities of the service provider (i.e., the QoS 
parameter values in the one or more OSVs 120), it is determined that the quality 
20 of service defined by the QoS parameter values in the one or more RSVs can be 
provided by the service provider. 

In a preferred embodiment, the QoS parameters contained in each of the 
RSVs 1 10, the OSVs 120, and the NSV 130 will be the same. For example, if the 
RSVs 110 contain QoS parameters for bit rate and quality, then the OSVs 120 and 
25 the NSV 130 will also contain QoS parameters for bit rate and quality. Another 
QoS parameter that might be contained in each of the QoS vectors is a parameter 
representing a user's price sensitivity level. The value of this level may either be 
low or high. The use of this parameter within a RSV is explained above. With 
respect to the OSV, the significance of the price sensitivity level parameter is as 
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follows: If the network traffic is low or if the network is idle, the price sensitivity 
level within the OSV would be low. This means that the network is willing to 
provide a service or connection at little or no cost. Therefore, if the user's price 
sensitivity level is high, then a OSV with a low price sensitivity level would match 

5 this user requirement. On the other hand, the price sensitivity level within an 
OSV may be high. This may result from the network being busy with a high 
volume of traffic. In this case, a RSV with a low price sensitivity level would 
best match the OSV as the user does not mind paying more for the service. It 
should be noted, however, that if the price sensitivity level is low within an OSV, 

10 then the sensitivity level within a RSV is irrelevant. That is, if the network is 

willing to provide a connection at little or no cost, then it does not matter whether 
the user sensitivity level to price is high or low. If the level is high within an 
OSV on the other hand, then the user specified level has to be low to enable 
connection. 

15 The OSVs 120 may be generated by a bearer service, preferably based on 

measurements of interference, load and gain. According to an exemplary 
embodiment, the OSVs 120 are generated based on long-term measurements of 
interference, load and gain, and in accordance with techniques that are well-known 
in the art. If necessary, short-term measurements may also be considered in 

20 generating OSVs 120. 

In accordance with the second step in the three-step method of the present 
invention, the QoS parameter values contained in each of the RSVs and in each of 
the OSVs are scaled. This scaling may be performed on each parameter to 
convert the parameter to a norm such as, for example, a unitary norm. The 

25 reason for scaling is to evaluate each of the parameter values in a proper context 
as the parameters may not always be represented on a linear scale. One of the 
parameters, bit rate for example, may only be represented on a logarithmic scale. 
Delay, on the other hand, may be represented only on a negative scale. By 
normalizing the various parameters, a weight function may be assigned to one of 
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the parameters and another weight function may be assigned to another of the 
parameters. 

Another reason for scaling the various QoS parameter values is that in 
deciding which OSV best matches the user's requirements, the appropriate amount 

5 of deference should be given to each QoS parameter. For example, if bit rate is of 
utmost importance to the user, as compared to the other QoS parameters, such as 
delay and/or signal quality, then the bit rate parameter values will be scaled, 
relative to the other parameter values, to reflect that importance. Thus, in 
comparing the desirability between two different OSVs, wherein the first OSV 

10 contains a bit rate parameter value that is just marginally better than the bit rate 

parameter value in the second OSV, the first OSV might be selected as being more 
desirable over the second OSV, during the third step of the three-step method, 
despite the fact that the signal quality value reflected in the second QoS vector is 
far superior to the signal quality value reflected in the first QoS vector. 

15 As one skilled in the art will readily appreciate, scaling may be achieved in 

accordance with any number of well-known techniques. For example, a 
comparable scale might be maintained for each QoS parameter type (e.g., bit rate, 
signal quality). Then, during the second step of the three-step method, each of the 
various QoS parameter values contained in the RSVs and the OSVs would be 

20 mapped to the corresponding scale. By doing so, each QoS parameter value is 
adjusted to reflect the relative importance of the corresponding QoS parameter 
type. Alternatively, each QoS parameter type might be assigned a particular 
weighting factor. Then, during this second step, the appropriate weighting factor 
is applied to each QoS parameter value. However, regardless whether the former, 

25 the latter or some other alternative scaling technique is utilized, it will be 

understood that by scaling the various QoS parameter values, the appropriate 
amount of deference is given to each QoS parameter type. 

In accordance with the third step in the three-step method of the present 
invention, the one or more RSVs 110 are compared with the one or more OSVs 
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120, and if, as stated above, a match is achieved between the one or more RSVs 
110 and with the one or more OSVs 120, a negotiated QoS vector, NSV, 130 is 
generated. Of course, there are a number of different techniques that can be 
employed to accomplish this third step. Figures 2-4 illustrate a number of 

5 exemplary techniques for accomplishing the third step of the three-step method. 

Before describing each of the exemplary techniques depicted in Figures 2- 
4, it should be noted that if the RSVs 110, the OSVs 120 and the NSV 130 
contained N number of QoS parameters, then the graphs depicted in Figures 2-4 
would have N number of dimensions. However, in order to simplify the 

10 discussion of the various techniques that can be employed to accomplish the third 
step in the method of the present invention, the various QoS vectors depicted in 
Figures 2-4 contain only two QoS parameters, for example, bit rate and signal 
quality. Hence, the graphs depicted in Figures 2-4 are all two-dimensional 
graphs. 

15 In Figure 2, a first exemplary technique for accomplishing the third step in 

the three-step method of the present invention is illustrated. In the illustrated 
example, one RSV and two OSVs are present. The overlap area A r£>1 between 
the regions defined by OSVi and RSV, and the overlap area Aro2 between the 
regions defined by OSV2 and RSV are used for determining a NSV. As one 

20 skilled in the art will readily appreciate after reviewing Figure 2, the area below 
and to the left of OSVj represents a particular level of service as defined by the 
two QoS parameter values in OSVj, bit rate and signal quality. Similarly, the 
area below and to the left of OSV 2 represents a particular level of service as 
defined by the two QoS parameter values in OSV 2, again, bit rate and signal 

25 quality. In contrast, the area above and to the right of RSV represents the level of 
service being requested by the user. Accordingly, the overlap areas Aroi and 
Arq2 represent the difference between the level of service being requested by the 
user and the level of service being offered by the bearer as defined by OSV 1 and 
OSV2 respectively. 
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One of skill in the art will also understand that both the level of service 
associated with OSV^ and the level of service associated with OSV2 satisfy the 
user's service requirements as defined by RSV. However, the level of service 
associated with OSV \ is capable of providing a better bit rate than the level of 

5 service associated with OSV2. In contrast, the level of service associated with 
OSV2 is capable of providing a better signal quality than the level of service 
associated with OSVi . Therefore, a determination has to be made as to whether 
to choose the level of service associated with OSV \ or the level of service 
associated with OSV2. In accordance with this first exemplary technique, the 

10 largest overlap area is used to determine which level of service best satisfies the 
user's service requirements. The overlap areas are computed by computing the 
product of the difference between the parameters of the RSV and each of OSV, 
and OSV 2 . In this case, both OSVs satisfy the RSV, but the overlap area A rq2 is 
greater than the overlap area Arqi as the difference between each of the 

15 parameters of RSV and the corresponding parameters of OSV 2 is greater than the 
corresponding differences between OSV, and RSV. The greater overlap area 
indicates the OSV parameters satisfying the RSV parameters by a greater margin 
than with the smaller overlap area. Therefore, the level of service associated with 
OSV2 is determined to best satisfy the user's service requirements, and OSV 2 is, 

20 therefore, selected as the negotiated QoS vector, NSV. It should be pointed out 
that if an area results that is zero, no NSV is determined and the user may be 
blocked from establishing a connection or dropped in the case of a handoff . 

Figure 3 illustrates a second exemplary technique for accomplishing the 
third step in the method of the present invention. In accordance with this second 

25 exemplary technique, a determination is first made as to whether the level of 
service associated with each of OSVj and OSV2 meet the user's service 
requirements, that is, whether all of the QoS parameter values in each of OSV 1 
and OSV2 satisfy the QoS parameter values in the RSV. Then, considering only 
those OSVs that satisfy the user's requirements, the one OSV that has the longest 
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length is selected as the RSV, wherein the level of service associated with that one 
OSV is established as the level of service that best satisfies the user's service 
requirements. 

In this case, the longest length vector represents a preference for choosing 
5 the OSV which not only satisfies the RSV but also contains one parameter which 
satisfies the corresponding parameter in the RSV by the greatest margin. As 
illustrated in Fig. 3, both OSV, and OSV 2 satisfy the RSV. OSV, satisfies the bit 
rate parameter of RSV by a greater margin than does OSV, and OSV, satisfies the 
quality parameter of RSV by a greater margin that OSV , does. However, OSV, 

10 satisfies the bit rate parameter of RSV by a greater margin than OSV 2 satisfies the 
quality parameter of RSV. Therefore, OSV, is chosen as the NSV. 

It should be noted that Fig. 3 only illustrates the presence of one RSV and 
two OSVs. The technique described with respect to Fig. 3 may easily extend to a 
situation where multiple RSVs introduced and multiple OSVs are available. In 

15 this instance, each OSV is compared to one RSV and those OSVs that do not 
satisfy a first RSV will not be considered as candidates for being a NSV. This 
process may be repeated for all RSVs presented by the user. 

A third exemplary technique for accomplishing the third step in the method 
of the present invention is illustrated in Figure 4. In accordance with this 

20 technique, the user generates two requested QoS vectors RSVp and RSVjvj, as 
illustrated in Figure 4, wherein the QoS parameter values contained in RSVrj) 
represents the user's desired level of service, and wherein the QoS parameter 
values contained in RSVjvj represent the user's minimum acceptable level of 
service. The bearer, for example, then generates three OSVs, OSVq, OSVj and 

25 OSV2. In determining which of OSV j , OSV2 or OSV3 defines the level of 

service that best satisfies the user's requirements, the third exemplary technique 
first established whether any of OSV 1 , OSV 2 or OSV3 defines a level of service 
that fails to satisfy the user's minimum acceptable requirements, as defined by 
RSVm- In the example illustrated in Figure 4, it will be understood that only the 
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level of service defined by OSVq fails to satisfy the user's minimum requirements. 
Accordingly, OSVq is no longer considered. Next, a determination is made as to 
which of OSVj or OSV 2 defines the level of service that best satisfies the user's 
desired service, as defined by RSVrj. This is accomplished by comparing the 
magnitude of OSV! with the magnitude of OSV 2 , and selecting the OSV having 
the smallest magnitude. In the present example, the magnitude of OSV 2 (i.e., 
LRD02 ) is less man to magnitude of OSV \ (i.e., Lrd01>- Accordingly, the 
level of service defined by OSV 2 is established as being the one that most closely 
matches the user's desired service requirements, as defined by RSVp, and OSV2 
is chosen as the NSV. 

Figure 5 illustrates a situation where the bearer is unable to generate any 
offered vectors that define a level of service which satisfy the user's requirements, 
as defined by RSV. As illustrated in the example of Figure 5 , the bearer is only 
capable of providing a level of service as defined by OSV, wherein the signal 
quality associated with the level of service offered by the bearer satisfies the user's 
signal quality requirements but wherein the bit rate associated with the level of 
service offered by the bearer fails to satisfy the user's bit rate requirements. As 
the bearer is unable to offer a level of service that meets the user's service 
requirements, an empty NSV is generated (e.g., a QoS vector with each QoS 
parameter value set equal to zero, thereby indicating that the bearer was unable to 
offer a level of service acceptable to the user), in accordance with a preferred 
embodiment of the present invention. Accordingly, the user may have to submit a 
different RSV, i.e., one that defines a level of service that the bearer is capable of 
satisfying, or the user may have to negotiate with another service provider (i.e., 
bearer). In the event that the user is unable to negotiate an acceptable level of 
service with any service provider, the user may be blocked from establishing a 
connection or dropped in the case of a handoff . 

In addition to the exemplary QoS parameters discussed above, such as bit 
rate and signal quality, a generic price sensitivity level may also be included as 
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one of the QoS parameters considered in the decision as to which level of service 
best satisfies the user's service requirements. The value of this parameter would 
indicate the user's sensitivity level for the level of service defined by the other 
QoS parameter values in the RSV. 
5 The price sensitivity level may be utilized, for example, to alter the 

selection of the offered QoS vector, particularly when there are several offered 
QoS vectors which define a level of service that satisfy the user's requirements, 
and where the user has indicated a high sensitivity level. For instance, in the 
example described above with respect to Figure 2, OSV 2 was selected over 
10 OSV] because the level of service defined by OSV2 exceeded the user's 

requirements by a greater amount than the level of service defined by the OSV \. 
However, had the user indicated a high sensitivity level, OSV ] may have been 
chosen as the NSV over the OSV 2 . 

The present invention has been described in terms of specific embodiments 
15 to facilitate understanding. The above embodiments, however, are illustrative 
rather than restrictive. It will be readily apparent to one skilled in the art that 
departures may be made from the specific embodiments shown above without 
departing from the central spirit and scope of the invention. Therefore, the 
invention should not be regarded as being limited to the above examples, but 
20 should be regarded instead as being fully commensurate in scope with the 
following claims. 
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WHAT IS CLAIMED IS : 

1 . A method of negotiating a telecommunications connection comprising the 
steps of: 

introducing a first set of quality-of-service (QoS) parameter values 
5 representing a user's desired level of service; 

introducing a second set of QoS parameter values representing at least one 
offered level of service from a service provider; 

comparing the QoS parameter values in the first set with corresponding 
QoS parameter values in the second set; 
10 selecting a level of service offered by the service provider that best 

satisfies the user's desired level of service based on the step of comparing each of 
the QoS parameter values in the first set with at least one corresponding QoS 
parameter value in the second set; and 

establishing the telecommunications connection for the user as a function of 
15 the selected level of service offered by the service provider. 

2. The method of claim 1 wherein each of the first set of QoS parameter 
values is associated with a different QoS parameter type. 

3. The method of claim 2 wherein said second set of QoS parameter values 
comprises a plurality of subsets of QoS parameter values, and wherein each of the 

20 plurality of subsets contains a QoS parameter value for each of the QoS parameter 
types represented in the first set of QoS parameter values. 

4. The method of claim 3 wherein said step of comparing the QoS parameter 
values in the first set of QoS parameter values with corresponding QoS parameter 
values in the second set of QoS parameter values comprises the steps of: 
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establishing a first graphical space as a function of the first set of QoS 
parameter values; 

establishing a plurality of graphical spaces, wherein each of the plurality of 
graphical spaces is a function of the QoS parameter values in a corresponding one 
of the plurality of subsets of QoS parameter values; 

determining a plurality of overlapping regions, wherein each of the 
plurality of overlapping regions represents an overlapping space between the first 
graphical space and a different one of the plurality of graphical spaces; and 

comparing the size associated with each of the plurality of overlapping 



5. The method of claim 4 wherein said step of selecting a level of service 
offered by the service provider that best satisfies the user's desired level of service 
comprises the step of: 

selecting a level of service offered by the service provider as a function of 
the size associated with each of the plurality of overlapping regions. 

6. The method of claim 5 wherein said step of selecting a level of service as a 
function of the size associated with each of the plurality of overlapping regions 
comprises the step of: 

selecting a level of service offered by the service provider based on the one 
subset of QoS parameter values which is associated with the largest of the plurality 
of overlapping regions. 

7. The method of claim 3 wherein said step of comparing the QoS parameter 
values in the first set of QoS parameter values with corresponding QoS parameter 
values in the second set of QoS parameter values comprises the steps of 

. establishing a plurality of magnitudes, wherein each of the plurality of 
magnitudes is a function of the first set of QoS parameter values and the QoS 
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parameter values in a corresponding one of the plurality of subsets of QoS parameter 
values; and 

comparing each of the plurality of magnitudes. 

8. The method of claim 7 wherein said step of selecting a level of service 

5 offered by the service provider that best satisfies the user's desired level of service 
comprises the step of: 

selecting a level of service offered by the service provider as a function of 
the plurality of magnitudes. 

9. The method of claim 8 wherein said step of selecting a level of service as a 
10 function of the plurality of lengths comprises the step of: 

selecting a level of service offered by the service provider based the one 
subset of QoS parameter values which is associated with the largest of the plurality 
of magnitudes. 

10. The method of claim 3 further comprising the steps of: 

15 determining whether the level of service associated with each of the 

plurality of subsets of QoS parameter values satisfy a minimum level of service 
desired by the user; and 

identifying only those subsets of QoS parameter values that satisfy the 
nimimum level of service desired by the user; 

20 establishing a plurality of magnitudes, wherein each of the plurality of 

magnitudes is a function of the first set of QoS parameter values and the QoS 
parameter values in a corresponding one of the subsets of QoS parameter values 
that satisfy the minimum level of service desired by the user; and 

comparing each of the plurality of magnitudes, wherein said step of 

25 selecting a level of service offered by the service provider comprises the step of: 
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selecting a level of service based on the one subset of QoS parameter 
values which is associated with the smallest of the plurality of magnitudes. 

11. In negotiating a telecommunication connection between a user and a bearer 
wherein the user specifies values for at least one of a plurality of parameters for a 

5 type of connection desired and the bearer makes available at least one subset of 
corresponding paremeter values, said parameters forming a user specified quality 
of service (QoS) vector, a method of matching the user specified values with an 
ability of the bearer for satisfying the user specified values comprising the steps 
of: 

10 accepting values for at least one of a plurality of QoS parameters specified 

by a user; 

comparing the user specified QoS parameter values with values of 
corresponding parameters available on said bearer; and 

establishing a connection between the user and a bearer that satisfies the 
15 user specified QoS parameter values. 

12. The method of claim 1 1 wherein a connection to the bearer is blocked if 
the user specified values for each of said parameters is not satisfied by the bearer. 

13. The method of claim 1 1 wherein the parameters comprise at least one of a 
bit rate, a bit error rate and a delay. 

20 14. The method of claim 13 wherein the parameters for which a user has 
specified values form a requested QoS vector (RSV). 

15. The method of claim 14 wherein the corresponding parameters available on 
a service provider form an offered QoS vector (OSV). 



2/5/2007, EAST Version: 2.1.0.14 



WO 00/41426 



PCT/SE99/02500 



-19- 

16. The method of claim 15 wherein the parameters representing the 
established connection form a negotiated QoS vector (NSV). 

17. The method of claim 15 wherein values for each parameter of an OSV are 
derived from long term measurements. 

5 18. The method of claim 15 wherein a connection is negotiated if the bit rate of 
an OSV is at least equal to the bit rate of the RSV and each of bit error rate and 
delay of the OSV are at most equal to the bit error rate and delay of the RSV. 

19. The method of claim 15 wherein a plurality of offered QoS vectors (OSVs) 
satisfy the requested QoS vector (RSV). 

10 20. The method of claim 14 wherein the user specifies a plurality of values for 
each of a plurality of parameters that form a plurality RSVs. 

21. The method of claim 20 wherein the user specified values form two RSVs. 

22. The method of claim 21 wherein the specified values for the two RSVs are 
desired values and acceptable values. 

15 23. The method of claim 16 wherein an NSV is a zero vector if each of the 
parameters of at least one OSV does not satisfy a corresponding parameter of a 
RSV. 

24. The method of claim 13 wherein the user specified parameters further 
include a price sensitivity level that is tolerated by the user. 
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